examples: a SYCL kernel and a HIP kernel behind the seam example 09 established - #575

…t cannot

Synchronised with the fixture the same island came from. Three things were
needed to make "the island returns a code" true, and only two of them are a
catch: the catch inside the buffer scope, the queue's asynchronous handler --
without which SYCL's default handler calls std::terminate, which no catch can
intercept -- and, for the third, a build-time warning from the rule, because a
missing device image is thrown from inside the SYCL scheduler and reaches
neither path.

…only tested by the configuration that fails

Two hypotheses were wrong before the backtrace settled it, and both were worth
fixing anyway because each terminates on some machine. The actual cause reaches
neither the caller's frame nor the queue's asynchronous handler, so the rule
states it at build time instead.

…d take

Four properties a consumer can rely on across all four lanes, each enforced by
something rather than asserted: the device is spelled once, the engine knows no
vendor name, no device command line reaches the host, and a payload is
reachable rather than merely installed. Three open items with the measurement
that would close each.

Found by the host verification run, not by building on this machine.
`nvidia_hip_runtime_api.h` includes <cuda_profiler_api.h> at its second line
and CUDA ships that header in its own component, so a machine with a host CUDA
installation supplies it from /usr/include and the build works while depending
on something it never declared. The fixture in mcpp-plugins gained the entry
when CI refused it on a runner; the example is the same shape and had the same
gap.

V4 with this: 0 assertions failed -- both examples answer 12 24 36 48 on the
device and again under --no-accel.

…it built against

Two findings from the sandbox run, and the second is the more useful.

EXAMPLE 11 STILL CARRIED THE PRE-2026.09.07 SHAPE: `compat:cuda-runtime`
beside `compat:sycl-runtime`, plus the driver sentinel. The whole point of the
adapter's 2026.09.07 version is that a SYCL project does not declare CUDA --
the SYCL runtime's back end dlopens the driver, so the adapter carries that
hop. The fixture in mcpp-plugins was updated when the adapter was; the example
was copied from it before that and kept the old form.

SECTION G WAS READING A FARM THE EXAMPLE HAD NOT USED. It picked one out of the
store by `sort -V | tail -1`, and a store that has seen two adapter versions
holds two farms. In the sandbox that reported `ok` for every soname of the
2026.09.06 farm while the example under test built against a different one --
the same shape the round-3 notes record as "the report was chosen by
`ls | head -1`", and the reason those notes exist.

It now reads the directory the example's own `resolution.json` names, and says
so out loud when it cannot: a run with no example build prints `note: falling
back to the newest farm in the store` rather than quietly measuring something
else. Two attempts were needed -- the first looked for `target/*/resolution.json`
where the file is two levels down, which the note caught rather than hid.

A property this exposed and the recipe comment gets wrong is recorded in a
follow-up: `compat.sycl-runtime` has ONE `install()` for both versions and
never reads `pkginfo.version()`, so 2026.09.06 does NOT "install the farm it
always did" -- it installs whatever the current recipe installs. Only the
descriptor entry is frozen.

V4 after both fixes: 0 assertions failed, with section G naming the 2026.09.07
farm and no fallback.

…7.10

7.3 now carries what each row was decided by rather than that it was done. 7.9
lists the eight defects with the method that found each, because the method is
the reusable part -- and names the shape four of them share: a criterion
pointing at the wrong object, which then answers ok. The mechanical lesson is
that a check which selects its own object must print which one it selected;
section G now does, and that line is what turned the last of these from a false
pass into a visible one.

7.10 records the one red this round did not cause: ci-fresh-install fails in
apt-get inside a debian:11 container on five consecutive commits, two of them
before this round. Diagnosed (the 404'd URL returns 200 from here, so a CDN
node was at fault) and deliberately not patched, because it cannot be verified
from this machine.